drivers/input: partial fix of indistinguishable ASCII and special keycodes - #19577
Conversation
bfbc6b6 to
b872b73
Compare
github-actions
Bot
added
Arch: simulator
acassis
left a comment
acassis
left a comment
There was a problem hiding this comment.
@ppisa thank you very much. I think this modification needs to be Documented in some place, maybe an Introduction to Input Device Drivers explaining the limitations, etc could be created here: https://nuttx.apache.org/docs/latest/components/drivers/character/input/index.html
|
…codes As analyzed, the NuttX initial keyboard API design uses event type KBD_SPECPRESS/KBD_SPECREL to deliver special keys and KBD_PRESS/KBD_RELEASE to deliver ASCII codes. But it seems that this design choice has not been followed in virtio-input, goldfish_events and sim_keyboard designs and result is that external keyboard special keys events are mapped to KEYCODE_xxx values which start from 0 and overlaps with ASCII keys. The issue is tracked under apache#19527 number. This set of changes correct events reporting for mentioned keyboards to report right event type for special keys. The solution is only partial at this phase. Virtual and more complex keyboards usually deliver key pressures as scancodes (key position on keyboard) and mapping to ASCII for keys which corresponds to letter and other similar keys lacks mapping of national alphabets, second row symbols and switch to capital letter according to modifiers. Signed-off-by: Pavel Pisa <pisa@fel.cvut.cz>
b872b73 to
c4ca7e6
Compare
|
@acassis , this is in the fact not API modification but attempt to follow what has been architected in the code long time ago. Some more detailed information about internal lower to upper level keyboard API would worth to be added. The event types are already described in https://nuttx.apache.org/docs/latest/components/drivers/character/input/keypad-keyboard.html But I am on vacations next week and I have a lot to resolve in the projects related to NuttX, RTEMS, etc. So I think these fixes worth to be included. I cannot provide any promise when I could get to documenting what are the APIs already provided by NuttX before. |
3 participants
Summary
As analyzed, the NuttX initial keyboard API design uses event type KBD_SPECPRESS/KBD_SPECREL to deliver special keys and KBD_PRESS/KBD_RELEASE to deliver ASCII codes.
But it seems that this design choice has not been followed in virtio-input, goldfish_events and sim_keyboard designs and result is that external keyboard special keys events are mapped to KEYCODE_xxx values which start from 0 and overlaps with ASCII keys.
The issue is tracked under #19527 number.
This set of changes correct events reporting for mentioned keyboards to report right event type for special keys.
The solution is only partial at this phase.
Virtual and more complex keyboards usually deliver key pressures as scancodes (key position on keyboard) and mapping to ASCII for keys which corresponds to letter and other similar keys lacks mapping of national alphabets, second row symbols and switch to capital letter according to modifiers.
Impact
Any attempt to use virtio-input, goldfish_events and sim_keyboard is broken, keys
which could be delivered as ASCII codes are often incorrectly remapped
to special key code but delivered as regular ASCII keys or they are delivered
as scancodes. Special keys are not marked as special so they are incorrectly
interpreted as ASCII coded.
Testing
The code has been tested with SIM BSP and updated Microwidows example
as well as with qemu-intel64:fb/qemu-intel64:mw configuration.
In this case multiple keyboard options have been used.
Invocation with VirtIO keyboard
Invocation with raw USB keyboard
It would worth to test code with some other NuttX demos which are know
to work with both special keys and keys reported in ASCII range.